Network equipment and a method for monitoring the start up of such equipment

ABSTRACT

The invention concerns a network equipment for connection to a local network and a method for monitoring the start up of a such an equipment. This equipment comprises a persistent memory for storing software and advantageously also comprises:
         communication means for connection to said network,   means for monitoring the start up of the equipment in order to detect a software failure,   means for generating a software failure signal in response to the detection of a failure on the network, wherein said notification is broadcast on the network for reception by said at least one software server.

The present invention relates to a network equipment and to a method formonitoring the software start up of a such an equipment.

Stand-alone networking equipment, such as a DSL modem, a bridge or arouter or a combination thereof, is used for example to interface alocal area network with an access network such as the Internet.

Commonly, stand alone equipment comprise a persistent memory, alsocalled on board memory means, such as a read only memory (ROM) and/or anelectrically erasable programmable read only memory (EEPROM). Thismemory contains among others, data and software necessary to initiatethe start up and run the equipment such as equipment configurationparameters, boot software and firmware.

To secure their start up, some stand alone equipments contain two copiesof some of the items mentioned above i.e. the equipment configuration,the boot software and the firmware. But, some modems may have apersistent memory just large enough to contain a single copy of thesedata.

In that case, if these data are corrupted, the equipment ceasesfunctioning properly until the persistent memory recovers a new validfirmware or configuration or boot program.

This situation might occur, for example, when the modem downloadsupgraded software from an appropriate server. As the persistent memorycan hold only one copy of the software, the old software is erasedbefore the updated one is fully recorded. If the connection is cut offor if the equipment is powered down during the download, the software iscorrupted.

It may also happen that the equipment comes to a halt during the powerup phase or reboots automatically because of a software or hardwaredefault.

In such cases, the equipment usually ceases functioning properly andnotifies the problem status to the end user by means of a LED indicator.

It is known, for example from U.S. Pat. No. 6,526,092, to allow a modemto download updated operating code over a phone line to a host personalcomputer and reprogramming the modem's memory over a serial port fromthe host personal computer. This process is under user control.

The present invention proposes a network equipment for connection to alocal network, said network comprising at least one software server,said equipment comprising a persistent memory for storing software,characterized in that it comprises:

-   -   communication means for connection to said network,    -   means for monitoring the start up of the equipment in order to        detect a software failure,    -   means for generating a software failure signal in response to        the detection of a failure by the monitoring means, and for        automatically sending a notification of the failure on the        network, wherein said notification is broadcast on the network        for reception by said at least one software server.

Thus, the user need not intervene in the failure correction process,unless the server decides this is required. Preferably, the servercomprises an application for analysing the failure type and forautomatically taking corrective actions.

In particular, according to a preferred embodiment of the invention,when the failure is a software start up failure, the means forgenerating a failure signal are adapted to requesting the automaticdownload of replacement software in the memory means from the softwareserver.

Thus, this embodiment's persistent memory needs to hold only onesoftware copy and has the same level of robustness as an equipmentholding two copies of the software or data.

Advantageously, the software download is done without any delay.

The present invention also proposes a method for monitoring the softwarestart up of a network equipment, the equipment comprising a persistentmemory for storing software and communication means for connection to anetwork comprising at least one software server, this process comprisingthe steps of:

-   -   monitoring the software start up of the equipment in order to        detect a software start up failure,    -   generating a software start up failure signal in response to the        detection of a start up software failure,    -   automatically broadcasting the software failure signal on the        network for reception by said at least one software server.

The teaching of the present invention can be readily understood byconsidering the following detailed but non-restricting description of anembodiment of the invention, together with the drawings, wherein:

FIG. 1 shows a block diagram of a system encompassing the networkequipment according to the present embodiment;

FIG. 2 depicts schematically a flow diagram of a processing methodsuitable for use in the system of FIG. 1 and in accordance with theprinciples of the present embodiment; and

FIG. 3 depicts schematically a flow diagram of the method illustrated inFIG. 2 with more details.

FIG. 1 shows a block diagram of a system incorporating a stand-aloneequipment 1 according to the present invention.

This network equipment 1 consists in any device able to process datatransfer communication. It can be, for example, a DSL type modem oranother stand-alone networking equipment. The equipment is connected toa local area network 2, to which is also connected a server 3 and/or adevice with a failure processing application (not shown).

The network equipment 1 is provided with persistent on board memorymeans 4 such as an Electrically Erasable Programmable Read Only Memory(EEPROM). This persistent memory holds a plurality of items. Accordingto the present embodiment, it stores among others data and softwareprograms necessary for the start up and functioning of the equipment:e.g. equipment configuration parameters 5, a boot software 6 and afirmware 7.

The equipment configuration 5 is a set of parameters containing amongothers the serial number and the network address of the modem.

Firmware 7 consists in any software written in a memory that is noterasable by an application level software, i.e. which has a certainprotection. In the present embodiment, firmware comprises e.g. themodem's operating system. Although in what follows, the firmware may bereplace globally by a download, the firmware may comprise distinctitems, and the invention is not limited to a bulk download but alsoextends to testing and downloading separate items.

As a matter of fact, the stand-alone equipment 1 comprises also a dataprocessing unit such as a microprocessor running the different programsand a non-persistent memory, not represented for clarity reason. Priorto execution, software stored in the persistent memory is copied to thenon-persistent memory (e.g. RAM).

The stand-alone equipment comprises also a data transfer module 8between the on board memory means 4 and network communication means 9connected to the network 2.

This transfer module 8 can employ for example the standardized Bootstrapprotocol (BOOTP), and the file transfer protocol (TFTP) to exchangeinformation between the server 3 and the equipment 1 via the local areanetwork 2. The equipment being a DSL modem according to the presentembodiment, it also comprises a corresponding PSTN interface andassociated circuitry to carry out its DSL functionalities. These itemsare well known in themselves and not represented in FIG. 1.

Modules 8 and 10 may either be hardware implemented or be softwaremodules run by the microprocessor from the non-persistent memory.

According to this invention, the stand-alone equipment 1 comprises alsomonitoring means 10 able to control the start up of the software of theequipment.

These monitoring means 10 check, among other things, validity, presenceand correct start up of the firmware 7 and the validity of theconfiguration data 5. Checking of the boot software copy in persistentmemory is also possible, but will not be discussed in more detail.

In case of any problem during in particular the start up process, thesemonitoring means 10 generate a firmware start up failure signal which istransmitted by the transfer module 8 and the communication means 9through the data transfer network 2 to the software server 3.

This failure signal, notified to the software server 3, is associated toa BOOTP request of downloading of replacement firmware by the server. Aframe portion of the BOOTP protocol used for sending this failuresignal, specifies the kind of software to be downloaded or theappropriate failure signal. This frame portion can be, for instance, the“vendor specific optional field” of the BOOTP protocol.

It is assumed that an application in the data transfer network 2,illustratively the software server 3, maintains a data base whereinprogram codes and replacement software and/or configuration data arestored.

In response to this BOOTP request, this server 3 transmits replacementsoftware to the network equipment, through the network 2, using the TFTPprotocol of the transfer module 8 and the communication means 9.

In practice, the BOOTP message comprises a number of failure states ofthe equipment, following the process detailed below. Another device onthe local area network will interpret these states and decide on acorrective action, typically including a replacement software download,but may also include notifying failure information to a user.

Advantageously, the monitoring means 8 can also be associated to abutton 11 which can be operated manually by the user to trigger therequest of a firmware and/or boot software download over the network.

Preferably, a visual or a sounding alarm 12 is connected to themonitoring means 10 for notifying a start up failure to the user.

FIG. 2 shows a flow diagram which illustrates a simplified version ofthe start up process of the stand alone equipment 1 according to thepresent embodiment. The shown steps relate mainly to testing thevalidity and presence a software like for example a firmware in memory4.

At the time of the power on (step 20) of the stand-alone equipment 1,monitoring means 10 launch a firmware testing step 21 concerning thefirmware necessary to start up the equipment 1. If no problem isdetected during this testing step, monitoring means 10 check, in step22, if the firmware is stored in the on board memory means 4.

If the firmware is missing, the monitoring means 10 generate a softwarestart up failure signal F, and reboot the equipment 1.

At step 23, if the testing step 21 is not successfully performed, themonitoring means 10 request the downloading of a replacement firmwarefrom the software server 3 through the transfer network 2 by using theBOOTP protocol of the transfer module 8 and the communication means 9.

At step 24, the software server 3 downloads a replacement firmwarethrough the transfer network 2 by using the TFTP protocol of thetransfer module 8 and the communication means 9.

At step 25, the monitoring means 10 control the correctness of thedownloading. When, for example the downloading has been interrupted, themonitoring means 10 generate a specific firmware failure signal F(comprising the identification of the failure type), and reboot theequipment 1 so that a new download may be initiated.

If the tests are correctly performed, the monitoring means 10 load,during step 26, the firmware and set a start up failure flag and a timerto determine a start up time limit. The flag is reset by the firmware ifit performs its start up properly. If the software start up is notcompleted once the start up time limit is reached, the flag is stillset, and the monitoring means 10 generate a software start up failuresignal F (also comprising an identification of the failure type,different from the first failure type above), and reboot the equipment1. Otherwise, at step 27, when the software start up is properlyexecuted it resets the software start up flag and no failure signal isgenerated.

Advantageously, according to the embodiment, the network equipment 1provides an automatic request and an automatic downloading of areplacement software in case of firmware start up failure or absence offirmware. Thus, e.g. start up failures are repaired automatically andthe user does not even notice the existence of a failure.

Specifically, the block diagram of FIG. 3 shows the details of the startup process of the stand alone equipment according to the embodiment.

The process begins at step 30, when a power on condition is initiatedfor the network equipment. The process of FIG. 3 is then executed by themonitoring means 10, using the well known BOOTP and TFTP protocols.

At step 31, initial tests are executed. Typically, the monitoring means10 check the availability of the persistent memory 4 and the properoperation of the non persistent memory.

At step 32, advantageously and in accordance with the present invention,a determination is made as to whether there is an equipmentconfiguration failure or whether the end user has pressed the activationbutton 11 to request a software downloading.

If one of these situations occurs, monitoring means 10 jump in step 33,and control the validity of the configuration data stored in the onboard memory means 4.

Equipment configurations 5 are often secured by a signature or achecksum. This signature or checksum is registered in the on boardmemory means 4 of the equipment 1. A classical and easy way to controlthe validity of an equipment configuration consists in recalculating itschecksum and comparing it to the registered one. If there is a mismatch,the equipment configuration 5 is no more valid. In that case, themonitoring means 10 set up a corresponding failure flag 34.

Advantageously, this flag 34 is encoded to deliver information about thetype of failures encountered. In the above mentioned case, the failureflag 34 comprises an information status indicating the presence of anequipment configuration failure.

Depending on the type of configuration data, the configuration datafailure may or may not be correctable through a download. In the lattercase, the BOOTP message issued by the equipment is interpreted by othernetwork devices as indicating that the equipment cannot be used any moreand is to be considered as dead.

If the configuration is valid in step 33, that means that the end userhas pressed the button 11 to trigger the download of firmware. Thus, themonitoring means 10 set also a software start up failure flag 35. Thisfailure flag 35 specifies that the user has requested a firmwaredownload.

If no downloading has been requested and in the absence of an equipmentconfiguration's problem, the monitoring means 10 check, after step 32,the validity of the firmware program 7 registered in the on board memorymeans 4 during step 36.

A simple way to do that consists in controlling the presence and thevalidity of its verification pattern (FVP for Flash VerificationPattern). The verification pattern is a classical tool for checking theintegrity of software or data. When the firmware is successfullyrecorded in the persistent memory 4 a verification pattern is calculatedand also written into memory 4. Should the equipment suffer a powerfailure or another problem during the storage of the firmware, theverification pattern corresponding to this firmware is either not storedor wrong.

Therefore, at step 36, the monitoring means 10 check the validity of thefirmware with the help of the firmware verification pattern. If thepattern is not valid, then a failure flag 37 is set. As for the othertesting steps, this particular failure flag indicates the nature of thefailure.

At step 38, the monitoring means 10 check the setting of the failureflags 34, 35, 37. If at least one flag is set, the monitoring means 10will automatically send a failure signal to the server 3 through thetransfer network 2 using the BOOTP protocol of the transfer module 8 andthe communication means 9. This message contains the failure flag state.

Applications bundled with network devices, such as an application of thesoftware server 3, listen for these signals and interpret the failurestatus information. After interpretation of this information, theseapplications decide, preferably without any end user intervention, on anaction comprising at least one of starting a firmware download to thenetwork equipment 1 and/or notifying the problem to the user. e.g. incase of occurrence of a fatal configuration failure, the user isnotified since no correction of the failure may be possible. The usermay also be notified if a download is not performed correctly after acertain number of retries. A counter of tries may be implemented forthis purpose and increment appropriately after each BOOTP messagerequesting e.g. a firmware download.

Specifically, the transfer module 8 indicates the problem status in the“vendor optional specific field” of an appropriate BOOTP protocolmessage sent on the network by the monitoring means 10. This field is ofstandard use to communicate to an application certain restrictions oradditional client information.

In other words, the message is preferably broadcast on the network andnot specifically to a predetermined server. Any one of the devices onthe network may act as a server provided it has the right application tolisten to, analyze and respond to the message.

After its downloading, the replacement software is stored in thepersistent on board memory means 4. This step has reference 39.

At step 40, the monitoring means 10 control that the replacementsoftware has been downloaded without any interruption and that it hasbeen correctly recorded.

When the software downloaded is a firmware, the data processing unitchecks the replacement firmware and calculates its flash verificationpattern (FVP) and records it in the memory 4 at step 41.

If the replacement software is damaged or incorrectly downloaded orrecorded, the monitoring means 10 sets a corresponding failure flag 42.Then, the stand alone equipment 1 is rebooted. Of course, the flags arestored in such a way as to be unaffected by the rebooting process. Atstep 31, the device tests whether flag 42 is set and sends acorresponding BOOTP message to request a firmware download.

At step 43, if no failure flag has been detected at step 38, themonitoring means 10 control the presence of the firmware in the on boardmemory means 4. There are different methods available for checking thispresence. For instance, the firmware's presence can be checked with thedetection of a specified identification code in a fixed location of thefirmware code. Other methods can also be used in accordance with thisinvention.

If no software is registered, the monitoring means 10 set a failure flag44 and the modem is rebooted at step 30 to process the failure based onthe set flag as above.

If step 41 or step 43 are executed without any problem, the monitoringmeans 10 set a start up flag and trigger a start timer, at step 45,before loading and starting the firmware at step 46.

After a successful start up, the start up flag is reset by the firmware,confirming that it started properly. However, if the start up is notperformed before the start time has elapsed, the monitoring means 10 seta problem flag 48 and reboot the equipment at step 30 to process thecorresponding failure.

To summarize, the process of FIG. 3 defines five problem states:

-   -   software (firmware) start-up error: the firmware either halts        during start-up or reboots without correctly starting up;    -   invalid configuration;    -   failed software (firmware) download (e.g; interruption of        download process);    -   absence of software;    -   writing of downloaded software to persistent memory failed        verification pattern incorrect).

Other states may trigger a download of software:

-   -   a mechanical button of the device was pressed by the user to        request a firmware download;    -   the firmware received a request over the network to perform a        firmware update.

Flags are checked by the monitoring means either at the beginning of theboot process, or during its execution. A download can be requestedexplicitly, or the decision as to a download should be left to anapplication listening to the device's messages.

This invention is not restricted to the preferred embodiment herewithdisclosed. In particular, any kind of software or data can bedownloaded. And this process can also be performed with protocolsdiffering from the TFTP and BOOTP protocols.

1. Network equipment for providing a connection to a local network, saidlocal network comprising at least one software server, said networkequipment comprising: a memory for storing software; means for providinga connection to said local network; and means for monitoring a start upof the network equipment to detect a software start up failure, and forgenerating a software start up failure signal in response to detectingsaid software start up failure, said software start up failure signalbeing broadcast on the local network for reception by said at least onesoftware server, said software start up failure signal comprisinginformation specifying at least one of: (i) a nature of said softwarestart up failure, an identification of replacement software to bedownloaded, and an identification of a version of the software currentlystored in the memory; (ii) said nature of said software start upfailure, and said identification of replacement software to bedownloaded; and (iii) said nature of said software start up failure, andsaid identification of said version of the software currently stored inthe memory.
 2. The network equipment according to claim 1, wherein thesoftware comprises at least one of: a boot program; configuration data;and firmware.
 3. The network equipment according to claim 2, wherein thesoftware comprises said firmware, and the monitoring means comprises:means for checking a current firmware verification pattern; and meansfor generating said software start up failure signal when said currentfirmware verification pattern is not valid.
 4. The network equipmentaccording to claim 2, wherein the monitoring means comprises: means forchecking for a presence of the firmware in the memory; means forrebooting the network equipment if the firmware is not stored in thememory; and means for generating said software start up failure signalif the firmware is not stored in the memory.
 5. The network equipmentaccording to claim 2, wherein the software comprises said firmware, andthe network equipment comprises: means for writing a replacementfirmware verification pattern corresponding to replacement firmwaredownloaded in the memory if said replacement firmware is properlyrecorded in said memory.
 6. The network equipment according to claim 1,wherein the monitoring means comprises: means for calculating a checksumof the software currently stored in said memory; means for comparingsaid calculated checksum to a previously stored checksum; and means forgenerating the software start up failure signal when said calculatedchecksum is not identical to the previously stored checksum.
 7. Thenetwork equipment according to claim 1, wherein the monitoring meanscomprises: means for monitoring downloading of replacement software inthe memory; and means for rebooting the network equipment and forgenerating said software start up failure signal if a problem isdetected during said downloading.
 8. The network equipment according toclaim 1, wherein the monitoring means comprises: means for monitoring aprocess of loading said software in said memory; and means for rebootingthe network equipment and for generating said software start up failuresignal if a problem is detected during said loading.
 9. The networkequipment according to claim 1, wherein the monitoring means comprises:a timer to determine a time limit for a software start up; means forlaunching the software start up; and means for generating said softwarestart up failure signal if the software start up is not completed beforean end of the time limit.
 10. The network equipment according to claim1, further comprising user activation means connected to the monitoringmeans for enabling a user to manually request a download of replacementsoftware.
 11. The network equipment according to claim 1, furthercomprising an alarm connected to the monitoring means for communicatingthe software start up failure to the user.
 12. The network equipmentaccording to claim 1, wherein the monitoring means comprises: means forchecking a setting of a failure flag; and means for generating thesoftware start up failure signal and for transmitting the software startup signal on the local network in response to detecting that the failureflag is set.
 13. The network equipment according to claim 1, wherein anindication of the nature of the software start up failure comprises aseries of status flags.
 14. A method for monitoring a software start upfor network equipment, the network equipment comprising a memory forstoring software and a connector for providing a connection to a localnetwork comprising at least one software server, said method comprisingthe steps of: monitoring the software start up for the network equipmentto detect a software start up failure; generating a software start upfailure signal in response to detecting said software start up failure;and automatically broadcasting the software start up failure signal onthe local network for reception by said at least one software server,wherein the software start up failure signal comprises informationspecifying at least one of: (i) a nature of said software start upfailure, an identification of replacement software to be downloaded, andan identification of a version of said software currently stored in saidmemory; (ii) said nature of said software start up failure, and saididentification of replacement software to be downloaded; and (iii) saidnature of said software start up failure, and said identification ofsaid version of the software currently stored in said memory.
 15. Themethod according to claim 14, wherein the software start up failuresignal comprises a request to the at least one software server for thedownload of the replacement software in the memory.
 16. The methodaccording to claim 14, wherein the software start up failure signalcomprises an identification of the software start up failure foranalysis by the at least one software server.
 17. Network equipment forproviding a connection to a local network, said local network comprisingat least one software server, said network equipment comprising: amemory for storing software; means for providing a connection to saidlocal network; and means for monitoring a start up of the networkequipment to detect a software start up failure, and for generating asoftware start up failure signal in response to detecting said softwarestart up failure, said software start up failure signal being sentbroadcast on the local network for reception by said at least onesoftware server, said software start up failure signal comprisinginformation specifying a nature of said software start up failure. 18.The network equipment according to claim 17, wherein the softwarecomprises at least one of: a boot program; configuration data; andfirmware.
 19. The network equipment according to claim 18, wherein thesoftware comprises said firmware, and the monitoring means comprises:means for checking a current firmware verification pattern; and meansfor generating said software start up failure signal when said currentfirmware verification pattern is not valid.
 20. The network equipmentaccording to claim 17, wherein the monitoring means comprises: means forcalculating a checksum of the software currently stored in said memory;means for comparing said calculated checksum to a previously storedchecksum; and means for generating the software start up failure signalwhen said calculated checksum is not identical to the previously storedchecksum.